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[ABSTRACT] 



A system and method for providing a packet service to a user equipment 
when the user equipment moves to a second cell managed by a second base 
station controller, the user equipment requesting permission to receive the packet 
5 service in a first cell managed by a first base station controller, in a mobile 
communication system providing the packet service. The method includes 
transmitting by the first base station controller control information that has to be 
provided to the user equipment, and transmitting by the second base station 
controller the packet service to the user equipment via a radio access bearer. 

10 

[REPRESENTATIVE FIGURE] 

FIG. 7 

[INDEX] 

15 CRNC, SRNC, MBMS ATTATCH REQUEST, UE ID, MBMS SERVICE 
IDENTIFIER 

[TITLE OF THE INVENTION] 

APPARATUS FOR TRANSMITTING/RECErVING DATA ON HANDOVER 
20 IN MOBILE COMMUNICATION SYSTEM SERVING MULTIMEDIA 
BROADCAST/MULTICAST SERVICE AND METHOD THEREOF 

[BRIEF DESCRIPTION OF THE DRAWINGS] 

FIG. 1 schematically illustrates a structure of a mobile communication 
25 system for providing an MBMS service. 

FIG. 2 illustrates in detail a structure of the UTRAN 102 illustrated in 

FIG. 1. 

FIG. 3 schematically illustrates a structure of an upper layer of the 
UTRAN 102 illustrated in FIG 1. 
30 FIG. 4A schematically illustrates a configuration for providing an MBMS 

service in a mobile communication system to which an SGSN, an SRNC, and 
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UEs are set. 

FIG 5 is a signaling diagram illustrating a procedure for providing an 
MBMS service in a mobile communication system connected as illustrated in 
FIG 4A. 

5 FIG 6 is a signaling diagram illustrating a procedure for providing an 

MBMS service in a mobile communication system connected as illustrated in 
FIG 4B. 

FIG 7 schematically illustrates a configuration of a mobile 
communication system providing an MBMS service for performing a function 
10 according to an embodiment of the present invention. 

FIG. 8 is a signaling diagram illustrating a procedure for providing an 
MBMS service to a UE during handover from an SRNC to a CRNC according to 
an embodiment of the present invention. 

FIG. 9 is a flowchart illustrating a procedure for providing an MBMS 
15 service by an SGSN according to an embodiment of the present invention. 

FIG 10 is a flowchart illustrating a procedure for performing an MBMS 
service by an SRNC according to an embodiment of the present invention. 

FIG. 11 is a flowchart illustrating a procedure for providing an MBMS 
service by a CRNC according to an embodiment of the present invention. 
20 FIG. 12 is a flowchart illustrating a procedure for providing an MBMS 

service by a UE according to an embodiment of the present invention. 

FIG 13 is a flowchart illustrating a procedure for managing an MBMS 
context by an SGSN according to an embodiment of the present invention. 

FIGs. 14 through 16 are flowcharts illustrating an MBMS context 
25 management procedure by an RNC according to an embodiment of the present 
invention. 

FIG 17 schematically illustrates a structure of an L2/MAC layer for 
directly transmitting MBMS data from a CRNC to a UE according to an 
embodiment of the present invention. 

30 
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[DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)] 
[OBJECT OF THE INVENTION] 

[RELATED FIELD AND PRIOR ART OF THE INVENTION] 

The present invention relates generally to a mobile communication 
5 system, and more particularly, to an apparatus and method for providing a 
multimedia broadcast/multicast service (MBMS) when a user equipment (UE) 
performs handover to a cell of a different wireless network controller in a mobile 
communication system providing an MBMS service. 

10 Recently, due to the development of communication technology, a 

service provided by a mobile communication system is developing into 
multimedia multicast/multicast communication system for transmitting voice 
service data and high-capacity multimedia data such as packet data and circuit 
data. The service is also evolving into multimedia broadcast/multi-channel 

15 broadcast communication capable of transmitting a multimedia service. In 
order to support the multimedia broadcast/multi-channel broadcast 
communication, a multimedia broadcast/multicast service (hereinafter referred to 
as "MBMS") has been proposed in which one or several multimedia data sources 
provide a service to a plurality of UEs. The MBMS service supports multimedia 

20 data, such as real-time image and voice data, still image data, and text data. In 
addition, the MBMS service simultaneously provides voice data and image data, 
and requires a large amount of transmission resources. Therefore, the MBMS 
service is provided over a broadcast channel, because of the possibility that a 
plurality of services would be simultaneously provided within one cell. 

25 Furthermore, the MBMS service can provide a point-to-point (hereinafter 
referred to as "PtP") service for providing independent services to respective 
subscribers, and a point-to-multipoint (hereinafter referred to as "PtM") service 
for servicing the same MBMS data to a plurality of subscribers. A asynchronous 
mobile communication standard 3GPP mobile communication system to which 
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the MBMS service is applied will be described with reference to FIG 1. 

FIG 1 schematically illustrates a structure of a mobile communication 
system for providing an MBMS service. 

5 

FIG 1 shows an example of a communication network for an MBMS in a 
3 GPP including a UE 101, a UMTS (Universal Mobile Telecommunications 
System) radio access network (UTRAN) 102, a serving GPRS (General Packet 
Radio Service) support node (SGSN) 103 belonging to a core network (CN), a 
10 home location register (HLR) 104, a gateway GPRS support node (GGSN) 105, a 
broadcast/multicast service center (BM-SC) 106, a border gateway (BG) 108, a 
multicast broadcast source (MBS) 107, a contents provide (CP) 109, and a 
multicast broadcast source (MBS) 110. 

15 Hereinafter, components of the communication network for supporting 

an MBMS illustrated in FIG. 1 will be described in detail. 

The UE 101, a user device, directly receives MBMS data and includes 
hardware or software supporting the MBMS service. The UTRAN 102 is a radio 
20 communication network for connecting the UE 101 to the CN. A structure of the 
UTRAN 102 will be described with reference to FIG. 2. 

FIG. 2 illustrates in detail a structure of the UTRAN 102 illustrated in 

FIG L 

25 

Referring to FIG. 2, the UTRAN 102 includes a plurality of radio 
network controllers (RNCs), a plurality of Node Bs controlled by the RNCs, and 
a plurality of cells belonging to the Node Bs. FIG 2 shows one RNC 201 and a 
plurality of Node Bs, i.e., Node B#l 202, Node B#2 203, Node B#n 204 
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controlled by the RNC 201 and a plurality of cells, i.e., cell#l 205, cell#2 206, 
cell#m 207 belonging to the Node Bl 202 for facilitating understanding. The 
total number of Node Bs controlled by each RNC and the total number of cells 
belonging to each Node B are determined according to a service provider. The 
5 UE 101 is connected to the UTRAN 102 via a Uu interface and the Uu interface 
121 is a term used in the 3 GPP for referring to an interface between the UE and 
the UTRAN. 

The UTRAN 102 is connected to the SGSN 103 included in the CN via 
10 an Iu interface 122. The Iu interface 122 is a term used in the 3GPP for 
referring to an interface between components of the UTRAN and the CN. The 
roles of MBMS components illustrated in FIG. 1 are shown in Table 1 and 
interfaces between the MBMS components are shown in Table 2. 



[Table 1] 



No. 


Name 


Role 


101 


UE 


It receives an MBMS service and always services the 
MBMS service to user. 


102 


UTRAN 


It delivers MBMS data to a UE, and delivers an 
MBMS request from a UE to a CN. For more details, 
see FIG. 2. 


102 


SGSN 


It authenticates a UE requesting an MBMS service by 
receiving data from an HLR, and authenticates the UE 
by receiving a right to use an MBMS service requested 
by the UE from the HLR. It sets up a Radio Access 
Bearer (RAB) for the MBMS service requested by the 
UE. It supports the MBMS service even when a UE 
moves from cell to cell. It connects with an MBMS 
source via a GGSN. It collects accounting information 
for the MBMS service used by a UE. 
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104 


HLR 


It stands for Home Location Register, and manages 
authentication information for each UE and the 
contents for an MBMS service type available for each 
UE, 


105 


GGSN 


It stands for Gateway GPRS Service Node, and 
directly receives MBMS data to be provided to a UE 
from a Multicast/Broadcast Source 110 via a BM-SC 
106 and a BG 108, and transmits the received MBMS 
data to an SGSN. It collects accounting information of 
a UE, manages a moving situation of each UE, and 
manages service quality (QoS) of the MBMS service 
being provided to the UE. 


106 


BMSC 


It stands for Broadcast/Multicast Service Center, 
authenticates a contents provider, determines QoS of 
the MBMS service, performs error correction on 
MBMS data, provides accounting information to a 
contents provider, receives MBMS data from contents 
provider 109, and provides the received MBMS data to 
GGSN 105. It notifies a currently served MBMS 
service to UE. 


107 


Multicast/Broad 
cast Source 


It directly provides MBMS data to a GGSN. 


108 


BG 


It stands for Border Gateway, receives MBMS data 
from Multicast/Broadcast Source in a network 
currently not managed by the service provider, and 
transmits the received MBMS data to a GGSN. 


109 


Contents 
Provider 


It provides MBMS contents to BM-SC 106. 


110 


Multicast/Broad 


It directly provides MBMS data to a GGSN. 
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cast Source 



[Table 2] 



No. 


Name 


Role 


121 


Uu 


Interface between a UE and a UTRAN 


122 


Iu 


Interface between a UTRAN and a CN 


123 


Gr 


Interface between an SGSN and an HLR 


124 


Gn/Gp 


Interface between an SGSN and a GGSN 


125 


Gi 


Interface between a GGSN and a BM-SC 


126 


Gi 


Interface between a GGSN and a multicast/broadcast 
source 


127 


Gi 


Interface between a GGSN and a BG 


128 


Gn/Gp 


Interface between a BM-SC and a contents provider 


129 


Gi 


Interface between a BG and a multicast/broadcast source 



Names of the interfaces shown in Table 2 are defined in the 3 GPP, and 
5 the names of the interfaces are subject to change. 



For clarifying a description of the present invention, the detailed 
structure of an upper layer of the UTRAN defined in the 3GPP and channels 
between layers are shown in FIG. 3. 

10 

FIG. 3 schematically illustrates a structure of an upper layer of the 
UTRAN 102 illustrated in FIG. 1. 

Upper layer messages processed in the UTRAN are roughly classified 
15 into a control signal and user data. In FIG. 3, the control signal is represented by 
control plain (hereinafter, referred to as C-Plain) signaling 301, and the user data 
is represented by user plain (hereinafter, referred to as U-Plain) information 
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302, The C-Plain signaling 301 and the U-Plain information 302 are non-access 
stratum (NAS) messages, and the NAS messages represent messages unused for 
radio connection between the UE 101 and the UTRAN 102. Herein, the NAS 
message represents a message, the contents of which are not required to be 
5 known to the UTRAN 102. Unlike the NAS, a message directly used for radio 
connection between the UTRAN 102 and the UE 101 is referred to as access 
stratum (AS) message that represents data or control signaling used in a radio 
resource control (RRC) layer 303 and its lower layer. 

10 The RRC 303 controls Layer 1 (LI) 310, which is a physical layer 

related to connection between the UE 101 and the UTRAN 102, a medium access 
control layer of Layer 2 (L2/MAC) 308, a radio link control layer of Layer 2 
(L2/RLC) 306, a packet data convergency protocol layer of Layer 2 (L2/PDCP) 
304, and a broadcast/multicast control layer of Layer 2 (L2/BMC) 305, thereby 

15 controlling operations related to connection between the UE 101 and the UTRAN 
102, such as physical call setup, logical call setup, control information 
transmission/reception, and measurement data transmission/reception. 

The L2/PDCP 304 receives transmission data from a NAS layer, and 
20 transmits the received transmission data to the L2/RLC layer 306 using a 
corresponding protocol. The L2/BMC 305 receives data necessary for broadcast 
and multicast from the NAS layer, and transmits the received data to the L2/RLC 
306. 

25 The L2/RLC 306 receives a control message, transmitted from the RRC 

303 to the UE 101, processes the received control message in an appropriate 
format in a first RLC (RLC#1) 361 to an m th RLC (RLC#m) 362, and transmits 
the processed control message to the L2/MAC 308 using a logical channel 307. 
In addition, the L2/RLC 306 receives data from the L2/PDCP 304 and the 

30 L2/BMC 305, processes the received data in an appropriate format in a first RLC 
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(RLC#1) 363 to an n th RLC (RLC#n) 364, and transmits the processed data to the 
L2/MAC 308 using the logical channel 307. Here, the number of RLC layers are 
formed in the L2/RLC 306 is determined by the number of radio links between 
the UE 101 and the UTRAN 102. 

The logical channel 307 is roughly classified into a dedicated type 
assigned to a specific UE or a small number of specific UEs, and a common type, 
which is commonly assigned to a plurality of UEs. If a message transmitted over 
the logical channel 307 is a control message, the message is classified as a 
control type, while if a message transmitted over the logical channel 307 is a 
traffic message, or a data message, the message is classified as a traffic type. In 
Table 3 below, types and roles of logical channels used in the 3GPP are shown. 



[Table 3] 



Name 


Role 


BCCH 


It stands for Broadcast Control Channel, and is used for downlink 
transmission from a UTRAN to a UE, and for transmission of 
UTRAN system control information. 


PCCH 


It stands for Paging Control Channel, and is used for downlink 
transmission from a UTRAN to a UE, and is used in transmitting 
control information to a UE when a position of a cell to which the 
UE belongs is unknown. 


CCCH 


It is used for transmission of control information between a UE and 
a network, and is used when the UE has no channel connected to an 
RRC. 


DCCH 


It is used for PtP transmission of control information between a UE 
and a network, and is used when the UE has a channel connected 
to an RRC. 


CTCH 


It is used for PtM data transmission between a network and UEs. 
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DTCH 



It is used for PtP data transmission between a network and a UE. 



The L2/MAC 308 of FIG 3 manages radio resources between the UE 
101 and the UTRAN 102 and also manages a connection between the UE 101 
and the UTRAN 102, under the control of the RRC layer 303. In addition, the 
5 L2/MAC 308 receives signals on the logical channel 307 from the L2/RLC 306, 
maps the received signals to transport channels 309, and then transmits the 
mapped signals to the LI 310. In Table 4 below, types and roles of the transport 
channels used in the 3GPP are shown. 



10 [Table 4] 



Name 


Role 


BCCH 


It stands for Broadcast Control Channel, and is used for downlink 
transmission from a UTRAN to a UE, and for transmission of 
UTRAN system control information. 


PCCH 


It stands for Paging Control Channel, and is used for downlink 
transmission from a UTRAN to a UE, and is used in transmitting 
control information to a UE when a position of a cell to which the 
UE belongs is unknown. 


CCCH 


It is used for transmission of control information between a UE and 
a network, and is used when the UE has no channel connected to an 
RRC. 


DCCH 


It is used for PtP transmission of control information between a UE 
and a network, and is used when the UE has a channel connected 
to an RRC. 


CTCH 


It is used for PtM data transmission between a network and UEs. 


DTCH 


It is used for PtP data transmission between a network and a UE. 



In addition to the transport channels shown in Table 4, there are an 
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uplink shared channel (USCH) and a common packet channel (CPCH). However, 
since they are not related to the invention, a detailed description thereof will be 
omitted for simplicity. 

5 The transport channels 309 transmitted to the LI 310 are transmitted to 

the UE 101 or the UTRAN 102 after being mapped to actual physical channels in 
the LI 310. The physical channels include a primary common control physical 
channel (P-CCPCH) for transmitting a broadcast channel (BCH), a secondary 
common control physical channel (S-CCPCH) for transmitting a paging channel 

10 (PCH) and a forward access channel (FACH), a dedicated physical channel 
(DPCH) for transmitting a dedicated channel (DCH), a physical downlink shared 
channel (PDSCH) for transmitting a downlink shared channel (DSCH), a high 
speed physical downlink shared channel (HS-PDSCH) for transmitting a high 
speed downlink shared channel (HS-DSCH), and a physical random access 

15 channel (PRACH) for transmitting a random access channel (RACH). In addition 
to the above physical channels, there is a pilot channel, which is a pure physical 
channel that does not transmit upper layer data or control signaling, a primary 
synchronization channel, a secondary synchronization channel, a paging 
indicator channel, an acquisition indicator channel, and a physical common 

20 packet channel. 

FIG. 1 shows an example in which the MBMS is supported in the 3GPP 
standard, and FIGs. 2 and 3 show the structure of the UTRAN and the structures 
and functions of the LI, L2, and L3 of the UTRAN. 

25 

Based on the description with reference to FIGs. 1 through 3, a 
description will be made of some problems that may occur when an MBMS 
service is provided in a conventional mobile communication system that does not 
support the MBMS service by referring to FIGs. 4A through 6. 

30 
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FIG. 4A schematically illustrates a configuration for providing an MBMS 
service in a mobile communication system to which an SGSN, a servicing radio 
network controller (SRNC), and UEs are connected. 

5 Referring to FIG 4 A, an SGSN 401 of FIG. 4 A has the same function as 

described in conjunction with FIG. 1. An RNC 402 of FIG. 4A is an RNC in 
terms of a system and is classified into an SRNC and a controlling RNC (CRNC) 
according to the connecting relation with the UE. The SRNC is an RNC having 
all information on the UE, and assigns a serving radio network temporary 

10 identifier (S-RNTI) to the UE. When the UE moves to a new cell and the new 
cell is controlled by a particular RNC, not by the SRNC, the RNC is referred to 
as a CRNC, and the CRNC assigns a cell radio network temporary identifier (C- 
RNTI) to the UE and manages the UE. In FIG. 4A, UE#1 403, UE#2 404, 
UE#m 405 receive MBMS data from the SRNC, and also receive from the SRNC 

15 402 data, if any, transmitted over voice communication a dedicated control 
channel (DCCH) or a dedicated traffic channel (DTCH). 

FIG. 4B schematically illustrates a configuration for providing an MBMS 
service in a mobile communication system to which an SGSN, a SRNC, a CRNC, 
20 and UEs are connected. 

Referring to FIG 4B, when UE moves to another cell with the CRNC, it 
is provided with the MBMS. Prior to a description with reference to FIG. 4B, it 
will be assumed that UE#m 416 of FIG. 4B has moved to another cell after 

25 sending an MBMS service request to the SRNC 412, which is an SRNC for the 
UE#m 416, so that a RNC which controls the UE#m 416 can be the CRNC 413. 
In FIG 4B, the SGSN 411 has the same function as the SGSN 103 illustrated in 
FIG. L In other words, the SGSN 411 transmits MBMS data to SRNCs including 
UEs requesting the MBMS. A UE#1 414 and a UE#2 415 of FIG. 4B receive 

30 MBMS data or data transmitted over a DCCH or a DTCH from the SRNC 412. 
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UE#m 416 of FIG 4B is connected to the CRNC 413, and receives requested 
MBMS data from the SRNC 412 via the CRNC 413. Describing a relation 
between the CRNC 413 and the UE#m 416, the CRNC 413 can directly transmit 
to the UE#416 such signals as system information, i.e., signals transmitted over a 
5 common traffic channel (CTCH) or a common control channel (CCCH). 
However, the CRNC 413 receives control signaling and user information 
transmitted from the SRNC 412 over the DCCH and the DTCH except for the 
CTCH or the CCCH, and transmits the received control signaling and user data 
to the UE#m 416. In addition, an interface between the CRNC 413 and the 

10 SRNC 412 is an IuR interface, through which no signal can be transmitted except 
for the signals transmitted over the DTCH or the DCCH. Although it is assumed 
in FIG. 4B that the CRNC 413 manages only one UE, i.e., UE#m 416 for 
convenience of explanation, a plurality of UEs can simultaneously be managed 
by the CRNC 413 and the SRNC 412 in an actual situation. As mentioned above, 

15 the UEs simultaneously being managed by the CRNC and the SRNC must 
unconditionally receive MBMS data via the Iur interface in order to satisfy the 
standard specification proposed in the 3GPR When all the UEs simultaneously 
having the CRNC and the SRNC receive the same MBMS data, i.e., when the 
same MBMS data is provided to the respective UEs via the Iur interface, the 

20 same MBMS data is repeatedly transmitted, which causes a waste of wired 
resources. In addition, even though the CRNC provides the same MBMS service, 
the CRNC cannot directly transmit MBMS data to the UEs having the CRNC, so 
the same MBMS data is transmitted to the UEs having the CRNC and the UEs 
having the SRNC through a radio environment, thereby causing a waste of radio 

25 resources. 

Signaling diagrams of the MBMS according to the conventional standard 
illustrated in FIGs. 4A and 4B are shown in FIGs. 5 and 6. Prior to a 
description with reference to FIG. 5, it will be assumed that an SRNC is not 
30 currently providing an MBMS service, i.e., the SRNC receives the MBMS from 
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an SGSN. 



FIG 5 is a signaling diagram illustrating a procedure for providing an 
MBMS service in a mobile communication system connected as illustrated in 
5 FIG4A. 

Referring to FIG 5, a BMSC 501 transmits MBMS data to a GGSN 511, 
and the GGSN 511 transmits MBMS data needed in the SGSN 521, extracted 
from the MBMS data, to the SGSN 521. Meanwhile, the UE 541 transmits an 

10 Activate MBMS Context Request message to the SGSN 521 in order to receive 
an MBMS service. Here, the "MBMS context" represents a set of information 
related to an MBMS service that the UE 541 desires to receive. Upon receiving 
the Activate MBMS Context Request message, the SGSN 521 transmits to the 
SRNC 531 an MBMS Notification message, which is a response message for the 

15 Activate MBMS Context Request message. Upon receiving the MBMS 
Notification message, the SRNC 531 transmits an MBMS Notification message 
to the UE 541. Here, the "MBMS Notification" indicates that an MBMS service 
requested by the UE 541 is to be performed. The SGSN 521 has an MBMS 
context, and the contents of the MBMS context can become a list of packet data 

20 protocols (PDPs) for a plurality of MBMS services that can be served by the 
SGSN 521. The PDP list can include addresses for the MBMS services, and such 
packet protocols as X.25 or IP (Internet Protocol) can be used as the PDP. The 
SGSN 521 transmits to the SRNC 531 an MBMS RAB Setup Request message 
for requesting setup of a radio access bearer (RAB) in order to transmit MBMS 

25 data. The SRNC 53 1 transmits to the SGSN 521 an MBMS RAB Setup Complete 
message, which is a response message for the MBMS RAB Setup Request 
message. The SGSN 521 transmits the MBMS data to the SRNC 531 through the 
set MBMS RAB. The SRNC 531 transmits to the UE 541 an RB for MBMS data 
Setup message for requesting setup of a radio bearer (RB) over which the MBMS 

30 data can be transmitted to the UE 541. Upon receiving the RB for MBMS data 
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Setup message, the UE 541 transmits to the SRNC 531 an RB for MBMS data 
Setup Complete message as a response message for the RB for MBMS data 
Setup message. Upon receiving the RB for MBMS data Setup Complete message, 
the SRNC 531 transmits MBMS data to the UE 541. In the meantime, MBMS 
5 RAB Release 527 and MBMS radio release 546 indicate suspension of the 
MBMS service transmitted from the SGSN 521 to the UE 541 via the SRNC 531 
and release of related wired and wireless resources after the UE 541 requests 
MBMS deactivation to the SGSN 521. 

10 FIG. 6 is a signaling diagram illustrating a procedure for providing an 

MBMS service in a mobile communication system connected as illustrated in 
FIG. 4B. 

Referring to FIG. 6, a signaling diagram used in FIG. 4B is illustrated in 
15 which it will be assumed in FIG. 6 that a UE simultaneously has a CRNC and a 
SRNC as the UE moved to a new cell after transmitting an Activate MBMS 
Context Request message to a SRNC, and the UE does not exchange DCH 
signals with the SRNC. More specifically, a connection relation between the UE 
640 and a UTRAN is roughly divided into an idle mode and a connection mode. 
20 The connection mode is divided into a URA_PCH state, a CELL_PCH state, a 
CELL_FACH state, and a CELL_DCH state according to the type of transport 
channels used when the UE exchanges signals with the UTRAN. In the URA- 
PCH state, the UTRAN does not know a position of the UE, and the UE receives 
only a PCH signal. In the CELLJPCH state, the UTRAN knows in which cell the 
25 UE is located, but the UE continues to receive only the PCH signal. In the 
CELL_FACH state, the UE exchanges signals with the UTRAN over RACH and 
FACH. In the CELL_DCH state, the UE exchanges signals with the UTRAN 
over DCH. In describing FIG. 6, it is assumed that the UE is in the CELLFACH 
state and the SGSN has already received necessary MBMS data from a GGSN. 

30 
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Referring to FIG. 6, an Activate MBMS Context Request 651 transmitted 
from the UE 640 to the SGSN 610 and MBMS data 601 transmitted from the 
GGSN 600 to the SGSN 610 have the same functions as the Active MBMS 
Context Request message 550 and the MBMS data 512 of FIG. 5. Further, the 
5 UE 640, which has moved to a cell managed by the CRNC 630 in the 
CELL_FACH state, transmits a Cell Update message to the SRNC 620. Upon 
receiving the Cell Update message, the SRNC 620 transmits to the UE 640 a Cell 
Update Confirm message as a response message for the Cell Update message. 

10 Upon receiving the Activate MBMS Context Request 651 from the UE 

640, the SGSN 610 transmits an MBMS Notification message to the SRNC 620. 
The SRNC 620 transmits an MBMS Notification message to the CRNC 630, and 
the CRNC 630 transmits the MBMS Notification message intact to the UE 640 
without knowing the contents of the MBMS Notification message. Here, the 

15 CRNC 630 provides radio resources for the UE 640 and simply relays signals 
transmitted and received to/from the SRNC 640. After transmitting the MBMS 
Notification message, the SGSN 610 transmits an MBMS RAB Setup Request 
message to the SRNC 620. Because the UE 640 currently exists in a cell 
managed by the CRNC 630, the SRNC 620 transmits an MBMS RAB Setup 

20 Request message to the CRNC 630. Upon receiving the MBMS RAB Setup 
Request message, the CRNC 630 transmits to the SRNC 620 an MBMS RAB 
Setup Complete message, a response message for the MBMS RAB Setup 
Request message. The SRNC 620 transmits an MBMS RAB Setup Complete 
message for RAB setup for receiving MBMS data to the UE 640. The 

25 transmission to the UE 640 is performed by simple relay of the CRNC 630. The 
UE 640 transmits to the SRNC 620 an MBMS RB Setup Complete message as a 
response message for the MBMS RB Setup message. The SGSN 610 transmits 
MBMS data to the SRNC 620, and the SRNC 620 transmits the MBMS data 603 
to the CRNC 630, and the CRNC 630 transmits the MBMS data 604 to the UE 

30 640. In FIG 6, an MBMS RAB release 605, an MBMS RAB release 606, and an 
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MBMS Radio release 607 indicate release of wired and wireless resources used 
for the MBMS among the SGSN 610, the SRNC 620, the CRNC 630, and the UE 
640. 

5 A description will now be made of the problems which may occur when 

an MBMS service is provided to a UE existing in a cell managed by a CRNC in a 
conventional mobile communication system that does not support the MBMS 
service as described in conjunction with FIG 4B. 

10 First, even when all UEs receiving MBMS data from a cell managed by 

an SRNC have moved, the SRNC must maintain an Iu interface and transmit the 
data received through the Iu interface to a CRNC to which the UEs have moved, 
via an Iur interface, thereby causing a waste of resources of the Iu interface 
between the SRNC and the SGSN. Moreover, if the same MBMS service was 

15 being provided in a cell managed by a CRNC, the CRNC repetitively receives 
MBMS data via the Iu interface between the SRNC and the SGSN even though it 
has already received the MBMS data to be provided to the UEs in its cell from 
the SGSN. 

20 Second, since the Iur interface between the CRNC and the SRNC 

transmits only dedicated data, if multiple UEs using the same MBMS service are 
under the management of the CRNC, the same MBMS service is unnecessarily 
repeatedly transmitted from the SRNC to the CRNC. That is, when the MBMS 
data is commonly provided in the same cell, only dedicated data is transmitted 

25 via the Iur interface. Therefore, in an MBMS service where several UEs are 
serviced all together within one cell, in order to transmit data to moved UEs via 
the Iur interface upon movement of the UEs, the same data must be repeatedly 
transmitted as many times as the number of the moved UEs. In this case, even 
though the CRNC is connected to the SRNC by wire, the same MBMS data 

30 requiring a relatively high data rate is repeatedly transmitted causing a waste of 
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wired resources. In addition, the MBMS data uses different radio resources, thus 
causing a waste of radio resources. In radio communication, the efficient use of 
radio resources is a very important factor, and the waste of radio resources affects 
the existing voice service and other services. This adds the repetitive operations, 
5 if the MBMS service was being served in the CRNC. At present, because an Iur 
interface for common data has not been defined yet, the MBMS service causes a 
considerable waste of wired and wireless resources. 

Third, even though the CRNC is already providing an MBMS service 
10 requested by the UEs having the CRNC, there is no way to directly transmit data 
to the UEs. Therefore, the same service is repeatedly transmitted to the UEs 
having the CRNC as the SRNC and the UEs having the CRNC as the CRNC. 
Since the UE that has moved from the SRNC to the CRNC must receive data 
from the SRNC via the Iur interface through the CRNC, even though the CRNC 
15 has the same data as the same MBMS service is being served in a CRNC's cell, 
the CRNC cannot provide the data to the UEs that have moved from the SRNC. 

For those reasons, the present invention suggests a new approach in which 
efficient resource use is provided for an MBMS service and MBMS data 
20 transmission and control signal transmission are performed separately. 

[SUBSTANTIAL MATTER OF THE INVENTION] 

It is, therefore, an object of the present invention to provide an apparatus 
and method for providing an MBMS service when a UE is handed over from an 
25 SRNC to a CRNC in a mobile communication system providing an MBMS 
service. 

It is another object of the present invention to provide an apparatus and 
method for providing an MBMS service without a separate Iur interface between 
30 an SRNC and a CRNC when a UE is handed over from the SRNC to the CRNC 
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in a mobile communication system providing an MBMS service. 

) 

It is further another object of the present invention to provide an 
apparatus and method for efficiently managing wired and wireless resources for 
5 an MBMS service in a mobile communication system. 

It is yet another object of the present invention to provide an apparatus 
and method for efficiently managing wired and wireless resources by adding new 
contents to an MBMS context to be managed by an SGSN. 

10 

It is still another object of the present invention to provide an apparatus 
and method for efficiently managing wired and wireless resources by defining a 
new message between an SRNC and a CRNC. 

15 It is still another object of the present invention to provide an apparatus 

and method for efficiently managing wireless resources by introducing a MAC of 
a new concept when the RNC manages wireless resources. 

It is still another object of the present invention to provide an apparatus 
20 and method to allow the MAC of the new concept to efficiently manage a PtP 
service and a PtM MBMS service. 

It is still another object of the present invention to provide an apparatus 
and method to allow the MAC of the new concept to efficiently perform a MAC 
25 management function in cooperation with an existing MAC. 

It is still another object of the present invention to provide an apparatus 
and method for optimizing efficient resource use and an MBMS service 
according to the movement of a UE by separating an MBMS data transmission 
30 path and a control signal transmission path via an Iu bearer. 
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It is still another object of the present invention to provide an operation 
of a new CRNC and a method introduced by separation of MBMS data 
transmission from control signal transmission when the MBMS service is 
5 provided. 

It is yet another object of the present invention to provide an apparatus 
and method for processing MBMS data transmission and control signals 
according to the movement of UEs provided with the MBMS service. 

10 

To achieve the above and other objects, the present invention provides a 
method for providing a packet service to a user equipment when the user 
equipment moves to a second cell managed by a second base station controller, 
the user equipment requesting permission to receive the packet service in a first 
15 cell managed by a first base station controller, in a mobile communication system 
providing the packet service. The method includes transmitting by the first base 
station controller control information that has to be provided to the user 
equipment, and transmitting by the second base station controller the packet 
service to the user equipment via a radio access bearer. 

20 

To achieve the above and other objects, the present invention also 
provides an apparatus for providing a packet service to a user equipment when 
the user equipment moves to a second cell managed by a second base station 
controller, the user equipment requesting permission to receive the packet service 

25 in a first cell managed by a first base station controller, in a mobile 
communication system providing the packet service. The apparatus includes the 
first base station controller for transmitting control information required for 
providing the packet service to the user equipment requesting permission to 
receive the packet service to the second base station controller and the second 

30 base station controller for receiving the control information for the packet service 
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from the first base station controller, setting up a radio access bearer according to 
the control information, and transmitting the received packet service to the user 
equipment via the radio access bearer. 

5 [CONSTRUCTION AND OPERATION OF THE INVENTION] 
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 

Several preferred embodiments of the present invention will now be 
described in detail herein below with reference to the annexed drawings. In the 
following description, a detailed description of known functions and 
10 configurations incorporated herein has been omitted for conciseness. 

FIG. 7 schematically illustrates a configuration of a mobile 
communication system providing an MBMS service according to an embodiment 
of the present invention. 

Referring to FIG. 7, it is assumed that a user equipment (UE) transmitted 
an Activate MBMS Context Request message in a serving radio network 
controller (SRNC), transmitted a Cell Update Confirm message after moving to a 
cell managed by a controlling RNC (CRNC), received an MBMS Notification for 
an MBMS service from a serving GPRS support node (SGSN), and transmitted a 
Paging Response message for the MBMS Notification message. Here, 
transmitting the Paging Response message is an optional process performed 
depending on an operation method by a network operator. 

25 An SGSN 701 is connected to an SRNC 702 (according to a connection 

relation of a UE#m 706 judging from a network) and a CRNC 703 (according to 
the connection relation of the UE#m 706 judging from the network) via an Iu 
interface 711 and an Iu interface 712, respectively. Here, the Iu interface 
indicates an interface between an SGSN and an RNC. The SGSN 701 transmits 

30 to the SRNC 702 MBMS data for UEs existing in cells managed by the SRNC 
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702, i.e., UE#1 704 and UE#2 705, and the CRNC 703 transmits MBMS data for 
the UE#m 706 so that the UE#m 706 can receive MBMS data under the control 
of the CRNC 703. The UE#m 706 is controlled by the SRNC 702, for control by 
a network and other services except an MBMS service, such as a radio bearer 
5 (RB) or a radio access bearer (RAB). That is, in providing an MBMS service to 
the UE#m 706, the invention transmits a control message via the SRNC 702 and 
the Iur interface 713, and transmits actual MBMS data via the CRNC 703. In 
other words, the invention proposes a service method for separating a control 
message transmission path and an MBMS data transmission path when a UE 

10 receiving MBMS service via an SRNC has moved to a cell managed by the 
CRNC. However, an operation caused by the separation of the control message 
transmission path and the MBMS data transmission path will be described later. 
The other services and a control message by the network are delivered to the 
UE#m 706 via an Iur interface 713 between the SRNC 702 and the CRNC 703. 

15 Here, the Iur interface represents an interface between RNCs. The UE#m 706 
receives MBMS data via the CRNC 703. Because the MBMS data is delivered to 
the UE#m 706 via the CRNC 703, it is possible to save wired resources of an Iur 
bearer between the SRNC 702 and the CRNC 703, and because the CRNC 703 
directly provides the MBMS service to the UE#m 706, the CRNC 703 can more 

20 efficiently manage wireless resources of cells managed by the CRNC 703 itself. 

A description will now be made of the contents of contexts to be created 
by entities, i.e., SGSN, SRNC, and CRNC, due to separation of a control 
message transmission path and an MBMS data transmission path upon 
25 movement of a UE in providing the MBMS service, a signaling flow between the 
respective entities, and a structure of the respective entities. 

A mobile communication system according to an embodiment of the 
present invention has a different MBMS context format from the conventional 
30 MBMS mobile communication system. The MBMS context represents the 
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contents necessary for providing an MBMS service, and respective entities 
existing in a network for providing the MBMS service store the MBMS context 
according to their roles. The MBMS contexts possessed by the SGSN, the SRNC, 
the CRNC, and the UEs may have different contents. Table 5 below shows new 
5 parameters for storing an MBMS context proposed in the invention. 



[Table 5] 



Element 


Existing 
Function 


Added Function 


Description 


SGSN 


MM context 
for each UE, 
MBMS PDP 
context for 
each MBMS 
service 


MM context for 
each UE + MBMS 
PDP context for 
each MBMS 
service with UE ID 
list 


- MM (Mobile Management) 
context for each UE is same as 
before. 

- RNC list of RNCs providing 
the MBMS service is added for 
each MBMS service. 

- For more detail, see FIG. 13. 


SRNC 


UE context 


UE context with 

MBMS 

information 


- MBMS service ID of MBMS 
service being nrovided to the 
UE is added to previously 
managed UE context. 

- For more detail, see FIGs. 14, 
15 and 16. 


CRNC 


none 


MBMS context for 
each service 


- Conventionally, there is no 
MBMS context for UE under 
CRNC. Even though there 
exists an MBMS context, it has 
the contents simply related to 
radio resource assignment. 

- As for the newly added 
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contents, a UE list is added for 
each MBMS service. 
- For more detail, see FIGs. 14, 
15 and 16. 



As illustrated in Table 5, the contents of an MBMS context possessed by 
each of the SGSN, the SRNC, and the CRNC include newly added parameters in 
addition to the parameters as the contents of an MBMS context managed in the 
5 conventional MBMS communication system. A detailed description of the 
MBMS context of Table 5 will be described later with reference to FIGs. 13 to 16. 
Since the contents of an MBMS context for a UE in the present invention are 
identical to the contents of an MBMS context in the conventional MBMS 
communication system. Therefore, they are not shown in Table 5. 

10 

Next, a process of providing an MBMS service according to an 
exemplary embodiment of the present invention will be described with reference 
to FIG. 8. 

15 FIG. 8 is a signaling diagram illustrating a procedure for providing an 

MBMS service to a UE during handover from an SRNC to a CRNC according to 
an embodiment of the present invention. 

Prior to a description with reference to FIG. 8, it is assumed that an 
20 MBMS service requested by a UE#m 840 is not currently being served in a 
CRNC 830, and the UE#m 840 transmitted an Activate MBMS Context Request 
message in an SRNC 820, transmitted a Cell Update Confirm message after 
moving to a cell managed by the CRNC 830, received an MBMS Notification 
message from an SGSN 810, and transmitted a Paging Response message for the 
25 MBMS Notification message. Here, transmitting the Paging Response message is 
an optional process performed depending on an operation method by a network 
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operator. 

Referring to FIG 8, the SGSN 810 transmits to the SRNC 820 an RAB 
Setup Request for MBMS data transmission (Step 856). Upon receiving the RAB 
5 Setup Request from the SGSN 810, the SRNC 820 transmits an MBMS Attach 
Request message to the CRNC 830 that manages a cell where the UE#m 840 is 
located, because the SRNC 820 detects that the UE#m 840 requesting the MBMS 
service does not exist in a cell managed by the SRNC 820 itself (Step 858). Here, 
the MBMS Attach Request message is a message newly proposed in the 

10 invention, which is needed by the SRNC to request the CRNC to provide the 
MBMS service even to a moved UE in order to provide the MBMS service to the 
UE having moved from the SRNC to the CRNC. In response to the MBMS 
Attach Request message, the CRNC performs an operation of transmitting 
MBMS data even to a moved UE, i.e., the UE#m 840, as the UE desiring to 

15 receive the MBMS service, i.e., UE#m 840, moves to a cell managed by the 
CRNC 830. Specifically, information that must be transmitted by the SRNC 820 
to the CRNC 830 through the MBMS Attach Request message includes a UE 
identifier (ID) of the UE#m 840, an MBMS service ID requested by the UE#m 
840, and RB information for transmitting a control message corresponding to the 

20 MBMS service ID. RB information for transmitting the control message includes, 
for example, a dedicated control channel (DCCH), and in this case, the RB 
information becomes DCCH-related information. Here, the UE ID for the UE#m 
840 indicates that the UE#m 840 receives an MBMS service from the CRNC 830, 
and the MBMS service ID indicates a type of the MBMS service to be received 

25 by the UE#m 840. The RB information is information that can be used in setting 
up a format of a dedicated channel (DCH) when the CRNC 830 provides an 
MBMS service on a point-to-point (PtP) basis, i.e., when the CNRC 830 provides 
an MBMS service using the DCH. 

30 Upon receiving the MBMS Attach Request message, the CRNC 830 

25 



transmits to the SGSN 810 an MBMS Service Request message since it does not 
have MBMS data related to the requested MBMS service (Step 859). Because it 
is assumed herein that the CRNC 830 is not providing the MBMS service, the 
CRNC 830 sends an MBMS service request to the SGSN 810 in order to 
5 providing the MBMS service to the moved UE#m 840. That is, because an Iu 
interface that must be set up to provide the MBMS service is not currently set up 
between the CRNC 830 and the SGSN 810, the CRNC 830 must request setup of 
the Iu interface. An operation performed when the CRNC 830 is providing the 
requested MBMS service will be described later with reference to FIGs. 14 to 16. 

10 Upon receiving the MBMS Service Request message, the SGSN 810 attaches an 
ID of the CRNC 830 to an MBMS packet data protocol (PDP) context, and then 
transmits an MBMS RAB Setup Request message to the CRNC 830 in order to 
transmit the requested MBMS data (Step 860). By doing so, an Iu interface for 
the MBMS service between the CRNC 830 and the SGSN 810 is set up. Here, 

15 the PDP context for each MBMS is a PDP context generated according to MBMS 
service types. The CRNC 830 transmits to the SGSN 810 an MBMS RAB Setup 
Complete message in response to the MBMS RAB Setup Request message (Step 
861). As described above, because the CRNC 830 does not provide the MBMS 
service, the CRNC 830 sends a request for information on RAB set up for the 

20 MBMS service to the SGSN 810 and the RAB is set up accordingly; In addition, 
the CRNC 830 transmits an MBMS Attach Response message to the SRNC 820 
(Step 862). Also, the MBMS Attach Response message is a message newly 
proposed in the invention, which is a response message for the MBMS Attach 
Request message. The MBMS Attach Response message is a message used by 

25 the CRNC 830 in attaching a moved UE, i.e., the UE#m 840, to a CRNC context 
managed by the CRNC 830 and then, informing the SRNC 820 that an Iu 
interface between the SGSN 810 and the CRNC 830 is set up. Here, the MBMS 
Attach Response message includes RB information to be used by the CRNC 820 
for MBMS data transmission. Therefore, the SRNC 820 transmits an RB Setup 

30 message to the UE#m 840 according to the RB information (Step 863), and the 
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UE#m 840 transmits an RB Setup Complete message to the SRNC 820 in 
response to the received RB Setup message (Step 890) so that the SRNC 820 
notifies completed setup of the RB. Thereafter, the CRNC 830 receives MBMS 
data from the SGSN 810 via an Iu interface (Step 864), and transmits the 
5 received MBMS data to the UE#m 840 (Step 865). As a result, in the present 
invention, the CRNC 830 can directly receive MBMS data from the SGSN 810 
via the Iu interface. 

The UE#m 840, if it desires not to receive the ongoing MBMS service 
10 any longer, transmits an MBMS Service Deactivation message to the SGSN 810 
(Step 866), and the SGSN 810 transmits an MBMS Service Deactivation 
message to the SRNC 820 (Step 867), and the SRNC 820 transmits again the 
MBMS Service Deactivation message to the CRNC 830 (Step 868). In addition, 
the SRNC 820 transmits an MBMS RB Release message to the UE#m 840 (Step 
15 869). Also, the MBMS Service Deactivation process will be described later with 
reference to FIGs. 14 to 16. As described above, it is noted that the moved UE#m 
840 is controlled by transmitting control information via the SRNC 820, and the 
MBMS data is transmitted via the CRNC 830. That is, a control message path is 
separated from a data transmission path. 

20 

The embodiment of the present invention described in conjunction with 
FIGs. 7 and 8 has the following advantages. 

1. Unnecessary transmission of the same MBMS data from the SRNC to 
25 the CRNC is prevented, thereby increasing efficiency of wired resources and 
network management. That is, as described above, unnecessary repeated 
transmission for the same MBMS data on an Iur interface, which is an interface 
between the SRNC and the CRNC, is prevented, and the SRNC transmits only 
control information and the CRNC transmits data, thereby securing efficient 
30 utilization of wired and wireless resources. 
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2. Because MBMS data of a UE#m having the CRNC as a CRNC is 
directly transmitted from the SGSN to the CRNC, unnecessary data transmission 
to the SRNC by the UE#m is prevented thereby securing efficiency of wired 

5 resources and network management. That is, if all UEs receiving an MBMS 
service from the SRNC have moved, MBMS data is transmitted via only the 
CRNC and MBMS data transmission to the SRNC is unnecessary. 
Conventionally, even though all UEs receiving an MBMS service from the 
SRNC have moved, since data must be transmitted via the SRNC, MBMS data 
10 transmission from the SGSN to the SRNC was required. However, according to 
the present invention, unnecessary transmission of MBMS data from the SGSN 
to the SRNC is not required. 

3. The CRNC can directly manage an MBMS service for UEs having the 
15 CRNC as a CRNC and UEs having the CRNC as an SRNC, thereby efficiently 

utilizing wired and wireless resources and managing a network. 

Next, an operation of an SGSN according to an exemplary embodiment 
of the present invention will be described with reference to FIG. 9. 

20 

FIG. 9 is a flowchart illustrating a procedure for providing an MBMS 
service by an SGSN according to an embodiment of the present invention. 

Referring to FIG 9, in step 901, the SGSN receives an MBMS Context 
25 Activation Request message from a particular UE#M. The MBMS Context 
Activation Request message is a message used by the UE#m in requesting a 
particular type of an MBMS service among a plurality of MBMS services 
provided by the SGSN. Upon receiving the MBMS Context Activation Request 
message, the SGSN determines whether the MBMS service type requested by the 
30 UE is an MBMS service type available to the UE by searching a home location 
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register (HLR). As a result of the determination, in step 902, if the MBMS 
service type requested by the UE#m is an MBMS service type available to the 
UE#m, the SGSN transmits to the UE#m an MBMS Notification message 
notifying that the MBMS service type requested by the UE#m is available and 
5 the requested MBMS service type will be initiated soon. In step 903, the SGSN 
receives a Paging Response message transmitted from the UE#m in response to 
the transmitted MBMS Notification message. The process of receiving a Paging 
Response message in response to the transmitted MBMS Notification message, 
as mentioned above, can be optionally selected according to system operation. 

10 

Upon receiving the Paging Response message from the UE#m the SGSN 
determines in step 904 whether the MBMS service type requested by the UE#m 
is being served in an RNC to which the UE#m currently belongs. Whether the 
MBMS service type requested by the UE is being served in an RNC to which the 

15 UE#m currently belongs can be determined by a list of RNCs providing the 
MBMS service in an MBMS context stored in the SGSN. If the MBMS service 
type requested by the UE#m is not being served in an RNC to which the UE 
currently belongs, the SGSN proceeds to step 905. In step 905, the SGSN 
transmits an MBMS RAB Setup Request message to an SRNC for the UE#m in 

20 order to provide the requested MBMS service type. However, if it is determined 
in step 904 that the MBMS service type requested by the UE#m is being served 
in an SRNC to which the UE#m currently belongs, the SGSN proceeds to step 
906. In step 906, the SGSN requests the SRNC for the UE#m to serve the 
requested MBMS service type to the UE#m. When requesting the SRNC for the 

25 UE#mto serve the requested MBMS service type to the UE#m, the SGSN can 
manage the current MBMS service providing situation for the UE#m by 
attaching an ID of the MBMS service requested by the UE#m to an MM context 
for the UE#m. 

30 In step 907, the SGSN awaits a response to the MBMS service type 
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requested by the UE#m from the SRNC for the UE#m. In the embodiment of the 
present invention, because it is assumed that the UE#m is located in a cell 
managed by the SRNC, not by the CRNC, the SGSN fails to receive a response 
from the SRNC. Therefore, the SGSN receives, through an MBMS RAB Setup 
5 Complete message or another message capable of transmitting the contents to the 
SGSN, a response indicating whether a service for the UE#m is provided by the 
SRNC after the SRNC completed a related operation with the CRNC for the 
UE#m or a request for the service is sent to another RNC. Furthermore, in the 
embodiment of the present invention, it is assumed that the MBMS service 

10 requested by the UE#m is not served in the CRNC, the SGSN receives in step 
908 an MBMS Service Request message from the CRNC. In step 909, the SGSN 
updates an RNC list in such a manner that an ID or the CRNC is added to the 
RNC list of each MBMS service type, managed by the SGSN. In step 910, the 
SGSN transmits an MBMS RAB Setup Request message for transmission of the 

15 MBMS data to the CRNC. In step 911, the SGSN receives an MBMS RAB Setup 
Complete message from the CRNC and proceeds to step 912. 

In step 912, the SGSN transmits the MBMS data provided by a 
multicast/broadcast-service center (BM-SC) to the CRNC. In step 913, the SGSN 

20 continuously monitors whether an MBMS Service Deactivation message from 
the UE#m. In the meantime, if the MBMS Service Deactivation message is 
received, the SGSN proceeds to step 914. That is, upon receiving the MBMS 
Service Deactivation message, the SGSN performs an operation of removing an 
MBMS service ID from an MM context of the UE#m, managed by the SGSN, 

25 and then determines in step 914 whether an MBMS RAB Release message for 
MBMS data transmission is received from a particular RNC connected to the 
SGSN. If an MBMS RAB Release message for the MBMS data transmission is 
received from the RNC, the SGSN proceeds to step 915. In step 915, the SGSN 
updates a list of UEs receiving MBMS services and a list of RNCs providing the 

30 respective MBMS services. If it is determined in step 914 that the MBMS RAB 
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Release message for MBMS data transmission is not received from the RNC, the 
SGSN proceeds to step 916. In step 916, the SGSN updates a list of UEs 
receiving the MBMS services, and then proceeds to step 917. In step 917, the 
SGSN delivers an MBMS service close message for the UE, i.e., an MBMS 
5 Service Deactivation message, to the SRNC for the UE#m, thereby suspending 
the MBMS service for the UE#m and ending the procedure. 

Next, an operation of the SRNC according to an exemplary embodiment 
of the present invention will be described with reference to FIG. 10. 

10 

FIG. 10 is a flowchart illustrating a procedure for performing an MBMS 
service by an SRNC according to an embodiment of the present invention. 

Referring to FIG. 10, in step 1001, the SRNC receives a Cell Update 
15 Completion message from a UE#m. Upon receiving the Cell Update Completion 
message from the UE#m, the SRNC perceives that the UE has a CRNC as it 
moves to another cell, i.e., as it is handed over. In step 1002, the SRNC transmits 
a Cell Update Confirm message to the UE#m to inform that it has perceived 
movement of the UE#m to the CRNC. In step 1003, the SRNC receives an 
20 MBMS RAB Setup Request message for transmission of MBMS data requested 
by the UE#m from the SRNC. In step 1004, the SRNC detects an MBMS service 
ID requested by the UE#m, a UE ID of the UE#m, and RB information over 
which a control message is being transmitted to the UE, from the received the 
MBMS RAB Setup Request message, and transmits the detected MBMS service 
25 ID, the UE ID and the RB information to the CRNC for the UE#m along with an 
MBMS Attach Request message. In step 1005, the SRNC updates an MM 
context of the UE#m by adding an MBMS service ID to be received by the 
UE#m to the MM context, and deletes the UE ID of the UE#m from the UE list 
of each MBMS service type, managed in the SRNC. 

30 
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In step 1006, the SRNC receives an MBMS Attach Response message 
from the CRNC. In step 1007, the SRNC detects information on RB to be used in 
transmitting MBMS data to the UE#m, included in the MBMS Attach Response 
message, and transmits an RB Setup message to the UE#m based on the detected 
5 RB information. In step 1008, the SRNC receives an RB Setup Complete 
message corresponding to the RB Setup message from the UE#m, and then in 
step 1009, the SRNC receives an MBMS Deactivation message for the UE#m 
from the SGSN. In step 1010, the SRNC deletes the MBMS service ID from the 
MM context of the UE#m, and in step 1011, the SRNC transmits an MBMS 
10 Service Deactivation message for the UE#m to the CRNC that provides an 
MBMS service to the UE#m. In step 1012, the SRNC transmits to the UE#m an 
RB Release message for releasing MBMS RB used in receiving the MBMS data, 
thereby ending the procedure. 

15 Next, an operation of the CRNC according to an exemplary embodiment 

of the present invention will be described with reference to FIG. 11. 

FIG 11 is a flowchart illustrating a procedure for providing an MBMS 
service by a CRNC according to an embodiment of the present invention. 

20 

Referring to FIG 11, in step 1101, the CRNC receives an MBMS Attach 
Request message from an SRNC for a UE#m. The CRNC detects a UE ID of the 
UE#m, an MBMS service ID, and DCCH RB information of the UE#m, included 
in the MBMS Attach Request message. In step 1102, the CRNC determines 
25 whether an MBMS service indicated by the MBMS service ID is currently being 
served. If an MBMS service indicated by the MBMS service ID is currently 
being served, the CRNC proceeds to step 1104. In step 1104, the CRNC adds a 
UE ID of the UE#m to a UE ID list of each MBMS service type, managed by the 
CRNC, and then proceeds to step 1109. 

30 
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However, if it is determined in step 1102 that an MBMS service 
indicated by the MBMS service ID is not being served, the CRNC proceeds to 
step 1103. In step 1103, the CRNC transmits an MBMS Service Request message 
to an SGSN in order to receive the MBMS service, and then proceeds to step 
5 1105. In step 1105, the CRNC receives an MBMS RB Setup Request message 
needed in receiving the MBMS data from the SGSN. In step 1106, the CRNC 
transmits an MBMS RB Setup Complete message to the SGSN as a response to 
the MBMS RB Setup Request message, and then in step 1107, the CRNC 
receives MBMS data from the SGSN. Alternatively, however, in step 1103, the 

10 CRNC may transmit an MBMS RAB Setup Request message to the SGSN while 
transmitting the MBMS Service Request message. In this case, the SGSN can 
inform the CRNC that transmission of the MBMS data requested by the CRNC 
was accepted, through an MBMS Setup Complete message. In step 1108, the 
CRNC adds a new MBMS service ID to an MBMS list managed by the CRNC, 

15 and adds the UE#m to a UE list of the MBMS service ID, and then proceeds to 
step 1109. 

In step 1109, the CRNC receives MBMS data requested by the UE#m, 
determines which RB the MBMS data is to be transmitted over, after adding the 

20 requested MBMS service type to a list. In step 1110, the CRNC transmits 
information on the determined RB to an SRNC for the UE#m, using an MBMS 
Attach Response message. In step 1111, the CRNC starts MBMS data 
transmission for the UE#m, and in step 1112, the CRNC receives an MBMS 
Service Deactivation message for the UE from the SRNC for the UE. In step 

25 1113, the CRNC determines whether there are any other UEs receiving an 
MBMS service type that the UE#m was receiving. If there is no UE receiving an 
MBMS service type that the UE#m was receiving, the CRNC proceeds to step 
1114. In step 1114, the CRNC transmits to the SGSN an MBMS RAB Release 
message for requesting or ordering release of an MBMS RAB previously set up 

30 for MBMS data transmission between the CRNC and the SGSN. In step 1116, 
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the CRNC deletes a UE ID of the UE#m from the UE list for the MBMS service, 
or deletes the MBMS service ID from an MBMS service list managed by the 
CRNC, and then proceeds to step 1117. 

5 However, if it is determined in step 1113 that there is another UE 

receiving an MBMS service type that the UE#m was receiving, the CRNC 
proceeds to step 1115. In step 1115, the CRNC deletes an ID of the UE from a list 
of the MBMS service that a UE#m was receiving. In step 1117, the CRNC 
transmits an MBMS Deactivation Response message for the UE#m to the SRNC 

10 for the UE#m, and then proceeds to step 1118. In step 1118, the CRNC releases a 
radio resource assigned to the UE#m, and then ends the procedure. Here, the 
radio resource is released in a case where the MBMS service was being served 
on a PtP (point-to-point) basis, and a second case where the MBMS service was 
being served on a PtM (Point to Multipoint) basis. In the first case, the radio 

15 resource assigned to the UE#m is released, and in the second case, a UE ID of 
the UE#m is released from the MBMS list. 

Next, an operation of the CRNC according to an exemplary embodiment 
of the present invention will be described with reference to FIG. 12. 

20 

FIG. 12 is a flowchart illustrating a procedure for providing an MBMS 
service by a UE according to an embodiment of the present invention. 

Referring to FIG 12, in step 1201, the UE transmits an Activate MBMS 
25 Context Request message to an SGSN. In step 1202, the UE#m receives from the 
SGSN an MBMS Notification message notifying that the MBMS service type 
requested by the UE#m was permitted and the corresponding MBMS service 
type will be started soon. Here, the UE#m may transmit or not transmit a Paging 
Response message to the SGSN in response to the received MBMS Notification 
30 message, and this is optional according to system operation, as mentioned above. 
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In FIG 12, it is assumed that the Paging Response message for the MBMS 
Notification message is not transmitted. In step 1203, the UE#m receives an 
MBMS RB Setup message for setup of an MBMS RB over which the MBMS 
data is to be transmitted from the SRNC for the UE#m. In step 1204, the UE 
5 transmits an MBMS RB Setup Complete message corresponding to the received 
MBMS RB Setup message to the SRNC. 

In step 1205, the UE#m receives MBMS data. In step 1206, if the UE#m 
detects that a user does not want to receive a corresponding MBMS service type 

10 any longer, the UE#m transmits an MBMS Service Deactivation message 
indicating expected suspension of MBMS data reception for the MBMS service 
type. In step 1207, the UE#m receives an MBMS RB Release message used in 
receiving MBMS data from the SRNC, and in step 1208, the UE#m transmits an 
MBMS RB Release Complete message to the SRNC as a response to the MBMS 

15 RB Release message after releasing MBMS RB used for reception of the MBMS 
data, thereby ending the procedure. 

Next, an MBMS context management process of an SGSN will be 
described with reference to FIG 13. 

20 

FIG 13 is a flowchart illustrating a procedure for managing an MBMS 
context by an SGSN according to an embodiment of the present invention. 

Referring to FIG 13, in step 1301, the SGSN is in a state where it stores 
25 a PDP list for MBMS services, a UE list of UEs receiving the MBMS services, 
for the MBMS services, and an RNC list of RNCs providing the MBMS services, 
for the MBMS services. In step 1302, the SGSN determines whether an Activate 
MBMS Context Request message is received from a particular UE. If an Activate 
MBMS Context Request message is received from a particular UE, the SGSN 
30 proceeds to step 1303. In step 1303, the SGSN determines whether an MBMS 
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service type requested by the UE is being served in an RNC to which the UE 
belongs. Here, an RNC list for the respective MBMS services are used in a 
process of determining whether an MBMS service type requested by the UE is 
being served in an RNC to which the UE belongs. Though not illustrated in FIG 
5 13, it is also possible to determine whether the requested MBMS service type is 
being provided from the SRNC by directly transmitting an MBMS RAB Setup 
Request message for MBMS data transmission to the SRNC for the UE without 
determining whether the requested MBMS service type is being provided from 
the RNC to which the UE belongs. 

10 

If the MBMS service type requested by the UE is being provided from 
the RNC to which the UE belongs, the SGSN proceeds to step 1311. In step 1311, 
the SGSN transmits an MBMS RAB Setup Request message to an SRNC for the 
UE. In step 1312, the SGSN receives an MBMS RAB Setup Complete message 

15 from the SRNC, and then the SGSN determines whether information included in 
the MBMS RAB Setup Complete message received from the SRNC has the 
contents indicating that the SRNC directly serves the MBMS service type in step 
1313. If the information has the contents indicating that the SRNC directly serves 
the MBMS service type, the SGSN proceeds to step 1331. In step 1331, the 

20 SGSN transmits MBMS data. In step 1332, the SGSN adds the RNC to an RNC 
list of RNCs providing the MBMS service, adds the UE to a UE list of UEs 
receiving the MBMS service, and then proceeds to step 1345. 

However, if it is determined in step 1313 that the information does not 
25 have the contents indicating that the SRNC directly serves the MBMS service 
type, the SGSN proceeds to step 1380. In step 1380, the SGSN proceeds to step 
1341 without adding the SRNC to an RNC list of each MBMS service. In step 
1341, the SGSN determines whether there is an MBMS RAB Setup Request 
message for an MBMS Data Transmission Request message from another RNC. 
30 Here, "another RNC" refers to a CRNC. If there is an MBMS RAB Setup 
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Request message for an MBMS Data Transmission Request message from 
another RNC, the SGSN proceeds to step 1342. In step 1342, the SGSN transmits 
an MBMS RAB Setup Complete message to the above-stated RNC, and then 
proceeds to step 1343. In step 1343, the SGSN transmits MBMS data to the 
5 above RNC. In step 1344, the SGSN adds the above RNC, i.e., a CRNC for the 
UE requesting the MBMS service, to an RNC list of RNCs providing the MBMS 
service, adds the UE to a UE list of UEs receiving the MBMS service, and then 
proceeds to step 1345. In addition, if it determined in step 1341 that there is no 
MBMS RAB Setup Request message for an MBMS Data Transmission Request 

10 message from another RNC, the SGSN proceeds to step 1351. In step 1351, the 
SGSN adds the MBMS service ID to a UE list of each MBMS service type, i.e., 
an MM context of the UE, and then proceeds to step 1345. If it is determined that 
no MBMS Data Transmission Request message was received from another RNC, 
it indicates that the requested MBMS service type is already being served by the 

15 above RNC. 

However, if it is determined in step 1303 that the MBMS service type 
requested by the UE is not being served in an RNC to which the UE belongs, the 
SGSN proceeds to step 1321. In step 1321, the SGSN transmits an MBMS 

20 Service Request message to an RNC (SRNC) to which the UE belongs. In step 
1322, the SGSN receives an acknowledgement message, i.e., MBMS Service 
Response message, for the MBMS Service Request message from the RNC 
(SRNC). In step 1323, the SGSN determines whether the MBMS Service 
Response message for the MBMS Service Request message has the contents 

25 indicating that the RNC directly supports the corresponding MBMS service type, 
if the MBMS Service Response message does not have the contents indicating 
that the RNC supports the corresponding MBMS service type, the SGSN 
proceeds to step 1341. However, if it is determined that the MBMS Service 
Response message has the contents indicating that the RNC supports the 

30 corresponding MBMS service type, the SGSN proceeds to step 1351. In step 
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1351, the SGSN adds only a UE ID of the UE to a UE list of UEs receiving the 
MBMS service. When it is determined that an MBMS RAB Setup Request 
message for the same MBMS Data Transmission Request message as the MBMS 
data requested by the UE was not received, it means that the MBMS service type 
5 requested by the UE is already being served in a CRNC for the UE. Therefore, 
the SGSN is allowed to add only the MBMS service ID to an MM context of the 
UE, and is not required to update an RNC list of each MBMS service. If it is 
determined in step 1323 that the RNC directly supports the corresponding 
MBMS service type, the SGSN adds only a UE ID of the UE to a UE list of UEs 
10 receiving the MBMS service in step 1351, and awaits reception of an MBMS 
Deactivation Request message from the UE in step 1345. 

In step 1345, the SGSN receives from the UE an MBMS Deactivation 
Request message for the MBMS service type being provided to the UE. In step 

15 1346, the SGSN determines whether an MBMS RAB Release message for the 
MBMS service is received from an RNC, i.e., SRNC or CRNC for the UE. If the 
MBMS RAB Release message is received, the SGSN proceeds to step 1347. In 
step 1347, the SGSN deletes the UE and the RNC from the UE list of UEs 
receiving the corresponding MBMS service type and the RNC list of RNCs 

20 providing the corresponding MBMS service type, respectively, and then proceeds 
to step 1349. In step 1349, the SGSN transmits an MBMS RAB Release 
Complete message to the RNC, and then ends the procedure. 

However, if it is determined in step 1346 that no MBMS RAB Release 
25 message for the MBMS service is received from the RNC, i.e., SRNC or CRNC 
for the UE, then the SGSN proceeds to step 1348. In step 1348, the SGSN deletes 
the UE from the UE list of UEs receiving the corresponding MBMS service type, 
and then ends the procedure. Deleting the UE from the UE list of UEs receiving 
the MBMS service means that the SGSN deletes the MBMS service ID from an 
30 MM context of the UE. 
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To summarize the MBMS context update procedure by the SGSN newly 
proposed in the invention in conjunction with FIG 13, the SGSN manages an 
MBMS list of MBMS services being provided to each UE, and manages an RNC 
5 list of RNCs separately providing respective MBMS services, so that the MBMS 
service is provided much easier. 

Next, an MBMS context management procedure by the RNC will be 
described with reference to FIGs. 14A, 14B, 15, and 16. In the MBMS context 

10 management procedure by the RNC, consideration is taken into a case where the 
MBMS service is provided on a PtP basis and a case where the MBMS service is 
provided in a PtM basis. Because the RNC can become either an SRNC or a 
CRNC according to circumstances, the RNC must have both the MBMS context 
management function of the SRNC and the MBMS context management function 

15 of the CRNC, described in conjunction with FIGs. 11 and 12. Describing again 
an MBMS context of an SRNC described in conjunction with Table 5, an SRNC 
adds an MBMS service ID to an MM context (UE position, UE state, and 
channel use situation of UE) of UEs managed by the SRNC. The MBMS service 
ID can become an MBMS service ID of an MBMS service being provided in an 

20 SRNC, and an MBMS service ID of an MBMS service being provided in a 
CRNC. In addition, describing again an MBMS context of a CRNC, a CRNC 
manages a list of UEs receiving the MBMS service, for the MBMS service being 
provided in the CRNC. That is, the RNC manages a list of MBMS services being 
provided to each UE in view of an SRNC, and manages a list of MBMS services 

25 being provided in each RNC in view of a CRNC. 

FIGs. 14A through 16 are flowcharts illustrating an MBMS context 
management procedure by an RNC according to an embodiment of the present 
invention. 

30 



39 



Referring to FIG. 14A, in step 1401, the RNC adds an MBMS service ID 
to a UE context of UEs receiving an MBMS service among the UEs in a UE 
context of UEs existing in the RNC, and manages a UE list of each MBMS 
service being served in the RNC. In 1402, the RNC determines whether an 
5 MBMS RAB Setup message for receiving MBMS data is received from the 
SGSN. If an MBMS RAB Setup message for receiving MBMS data is received 
from the SGSN, the RNC proceeds to step 1403. In step 1403, the RNC 
determines whether a UE scheduled to receive the MBMS data currently exists in 
a cell within the RNC. If a UE scheduled to receive the MBMS data does not 

10 currently exist in a cell within the RNC, the RNC proceeds to step 1411. In step 
1411, the RNC transmits an MBMS Attach Request message for the UE to an 
RNC that manages a cell where the UE is currently located. The contents of the 
MBMS Attach Request message have been described in conjunction with FIGs. 
11 and 12 so they will not be described again. In step 1412, the SRNC receives 

15 information on a channel for transmitting MBMS data to the UE, from an RNC 
managing a cell where the UE is located, through an MBMS Attach Response 
message. In step 1413, the SRNC transmits an MBMS RB Setup message to the 
UE using the received information. The SRNC receives an MBMS RB Setup 
Complete message from the UE in step 1414, and then deletes a UE ID of the UE 

20 from a UE list of each MBMS service, currently possessed by the SRNC, in step 
1415. If the UE was not receiving the MBMS service being served in the RNC, 
the step 1415 can be omitted. The procedure following the step 1415 is connected 
to B of FIG 16. 

25 In step 1421, if a UE scheduled to receive the MBMS data exists in the 

RNC, i.e., if the UE is located in a cell controlled by the RNC, the RNC serves as 
an SRNC. The RNC transmits an MBMS RAB Setup Complete message to the 
SGSN in step 1421, and then receives MBMS data from the SGSN in step 1422. 
Upon receiving MBMS data from the SGSN in step 1422, the RNC determines in 

30 step 1423 whether it will transmit the MBMS data on a PtP basis. Whether the 
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RNC serves the MBMS service on a PtP basis or on a PtM basis can be 
determined by the number of UEs expected to receive the MBMS service. That is, 
if the number of UEs scheduled to receive the MBMS data is smaller than a 
predetermined number, the RNC can select a method of transmitting MBMS data 
5 on a PtP basis, thereby reducing power consumption of a Node B. If the number 
of UEs scheduled to receive the MBMS data is larger than or equal to the 
predetermined number, the RNC can select a method of transmitting the MBMS 
data on a PtM basis, thereby to reducing power consumption of a Node B for the 
number of UEs. If the RNC determines to transmit the MBMS data to the UE on 

10 a PtP basis in step 1423, the RNC transmits an MBMS RB Setup message 
suitable for the PtP transmission to the UE in step 1424, and then transmits 
MBMS data after receiving an MBMS RB Setup Complete message from the UE 
in step 1425. In step 1428, the RNC creates a UE list for the MBMS service, and 
then adds the UE to the UE list for the MBMS service and adds an MBMS 

15 service ID of the MBMS service to a context of the UE. If the RNC determines to 
transmit the MBMS data on a PtM basis in step 1423, the RNC transmits channel 
information used for PtM transmission using an MBMS RB Setup message in 
step 1426, and then receives an MBMS RB Setup Complete message from the 
UE in step 1427. In step 1428, the RNC creates a UE list for the MBMS service, 

20 and then adds the UE to the UE list for the MBMS service and adds an MBMS 
service ID of the MBMS service to a context of the UE. The procedure following 
the step 1428 is connected to B of FIG. 16. 

Upon failure to receive an MBMS RAB Setup Request message for 
25 receiving MBMS data from the SGSN in step 1402 of FIG. 14A, the RNC 
proceeds to step 1430 in FIG. 14B. If a request for providing a particular MBMS 
service to a particular UE is received from the SGSN in step 1430, the RNC 
performs a corresponding operation in step 1431, and if the request is not 
received from the SGSN, the RNC proceeds to A of FIG. 15. Upon receiving a 
30 request for providing a particular MBMS service to a particular UE from the 
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SGSN in step 1430, the RNC determines in step 1431 whether a UE scheduled to 
receive the MBMS data is currently located in a cell within the RNC, and 
performs steps 1432 and 1441 according to the determination result. Even though 
the MBMS service is served in the RNC, if a UE scheduled to receive the MBMS 
5 service is not located in the RNC, i.e., if the UE is located in a cell controlled by 
a CRNC, step 1432 is a start point where the RNC serves as an SRNC. In step 
1432, the RNC transmits an MBMS Attach Request message for the UE to an 
RNC managing a cell where the UE is located. As indicated above, the contents 
of the MBMS Attach Request message are illustrated in FIGs. 11 and 12. The 

10 SRNC receives information on a channel for transmitting MBMS data to the UE 
from an RNC managing a cell where the UE is located, through an MBMS 
Attach Response message, in step 1433, and transmits an MBMS RB Setup 
message to the UE using information detected from the MBMS Attach Response 
message, in step 1434. The SRNC receives an MBMS RB Setup Complete 

15 message from the UE in step 1435, and then deletes the UE ID from a UE list of 
each MBMS service type, currently possessed by the SRNC, in step 1436. If the 
UE is not receiving an MBMS service in the RNC, the step 1436 can be omitted. 
The procedure succeeding the step 1436 is connected to B of FIG 16. 

20 When the MBMS service is being served in the RNC and a UE 

scheduled to receive the MBMS service exists in the RNC, i.e., when the UE is 
located in a cell controlled by the RNC, the step 1441 is a start point where the 
RNC serves as a SRNC. In step 1441, the RNC determines whether the MBMS 
data is being transmitted on a PtP basis. If it is determined in step 1441 that the 

25 MBMS data is being transmitted on a PtP basis, the RNC transmits an MBMS 
RB Setup message suitable for the PtP transmission to the UE in step 1442, and 
then transmits MBMS data after receiving an MBMS RB Setup Complete 
message from the UE in step 1443. In step 1446, the RNC adds the UE to a UE 
list for the MBMS service, and adds the MBMS service ID to a context of the UE. 

30 If it is determined in step 1441 that the MBMS data is being transmitted on a 
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PtM basis, the RNC transmits channel information used for PtM transmission to 
the UE using an MBMS RB Setup message in step 1444, and then receives an 
MBMS RB Setup Complete message from the UE in step 1445. In step 1446, the 
RNC adds the UE to a UE list for the MBMS service, and adds the MBMS 
5 service ID to a context of the UE. The procedure following the step 1446 is 
connected to B of FIG. 16. 

In step 1501 of FIG. 15, the RNC determines whether an MBMS Attach 
Request message for a UE in a cell managed by the RNC is received from 

10 another RNC. If the MBMS Attach Request message is not received, the 
procedure is connected to C of FIG 14A. That is, an MM context of UEs and a 
UE list of each MBMS service, managed by the RNC, are not changed. If an 
MBMS Attach Request message for a UE in a cell managed by the RNC is 
currently received from another RNC in step 1501 of FIG. 15, the RNC 

15 determines in step 1502 whether the requested MBMS service type is currently 
being served. The RNC proceeds to step 1503 or step 1521 according to the 
determination results in step 1502. In step 1503, when an MBMS service 
requested by another RNC is currently being served in the RNC, the RNC 
determines whether the MBMS data is being transmitted on a PtP basis. If it is 

20 determined in step 1503 that the MBMS data is being transmitted on a PtP basis, 
the RNC transmits channel information suitable for the PtP transmission to an 
SRNC for the UE through an MBMS Attach Response message in step 1505, and 
transmits MBMS data to the UE in step 1506. 

25 If it is determined in step 1503 that the MBMS data is being transmitted 

on a PtM basis, the RNC transmits channel information for the PtM transmission 
to an SRNC for the UE through an MBMS Attach Response message in step 
1504, and transmits MBMS data to the UE in step. In the PtM transmission, the 
step 1506 indicates that the UE receives previously existing MBMS data, and 

30 does not indicate assignment of a new radio resource. In step 1507, the RNC 
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adds the UE to a UE list for the corresponding MBMS service type. An operation 
of the RNC after the step 1507 is connected to B of FIG. 16. If it is determined in 
step 1502 that the requested MBMS service is not currently being served, the 
RNC transmits an MBMS RAB Setup Request message for reception of the 
5 MBMS data to the SGSN in step 1521, receives an MBMS RAB Setup Complete 
message for reception of the MBMS data from the SGSN in step 1522, and then 
receives MBMS data from the SGSN in step 1523. The RNC determines in step 
1524 whether it will transmit MBMS data requested by another RNC on a PtP 
basis or on a PtM basis. If it is determined in step 1524 that the MBMS data is to 
10 be transmitted on a PtP basis, the RNC transmits channel information for the PtP 
transmission to an SRNC for the UE through an MBMS Attach Response 
message in step 1526, and transmits MBMS data to the UE in step 1527. 

If it is determined in step 1524 that the MBMS data is being transmitted 
15 on a PtM basis, the RNC transmits channel information for the PtM transmission 
to the SRNC for the UE through the MBMS Attach Response message in step 
1525, and transmits MBMS data to the UE in step 1527. In the PtM transmission, 
the step 1527 does not indicate an assignment of a new radio resource because 
the MBMS data did not exist at a previous time. In step 1528, the RNC creates a 
20 UE list for the corresponding MBMS service type, and adds the UE to the UE list 
for the MBMS service. The procedure following the step 1528 is connected to B 
of FIG. 16. FIG. 16 is a flowchart illustrating an operation of the RNC when the 
RNC has received, from an SGSN or another RNC, an MBMS Deactivation 
Request message for a UE having the RNC as an SRNC or a CRNC. In step 1601, 
25 the RNC determines whether an MBMS Deactivation Request message of an 
MBMS service for a UE currently receiving the MBMS service has been 
received from an SGSN, and then proceeds to step 1602 and 1611 according to 
the determination results. 

30 If it is determined in step 1601 that an MBMS Deactivation Request 
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message for a UE currently receiving an MBMS service has been received from 
an SGSN, the RNC transmits to the UE an MBMS RB Release message for 
releasing MBMS RB over which the UE currently receives MBMS data, in step 
1602, and then receives an MBMS RB Release Complete message from the UE 
5 in step 1603. If it is determined in step 1601 that an MBMS Deactivation Request 
message for a UE currently receiving an MBMS service has not been received 
from an SGSN, the RNC determines in step 1611 whether an MBMS 
Deactivation Request message for a particular UE currently receiving an MBMS 
service has been received from another RNC. If it is determined in step 1611 that 

10 an MBMS Deactivation Request message for a particular UE currently receiving 
an MBMS service has not been received from another RNC, the RNC does not 
perform an operation of updating a UE list of each MBMS service and an MBMS 
service ID in an MM context of the UE, currently managed by the RNC. If it is 
determined that an MBMS Deactivation Request message for a particular UE 

15 currently receiving an MBMS service has been received from another RNC, the 
RNC transmits an MBMS Deactivation Confirm message for the UE to an SRNC 
for the UE in step 1612, determines in step 1613 whether the MBMS service 
which was being received by the UE was being served on a PtP basis, and then 
proceeds to step 1614 or 1615 according to the determination results. If it is 

20 determined in step 1613 that the UE was receiving an MBMS service 
corresponding to the MBMS Deactivation Request message on a PtP basis, a 
process of releasing a radio resource assigned to the UE is performed by the 
RNC in step 1614. However, if it is determined in step 1613 that the UE was 
receiving an MBMS service corresponding to the MBMS Deactivation Request 

25 message on a PtM basis, an operation of deleting a UE ID of the UE is performed 
by an SRNC in step 1615. 

The RNC determines in step 1604 of FIG. 16 whether there is anther UE 
receiving the MBMS service that the UE was receiving, and then performs step 
30 1605 and step 1606 according to the determination results. If there is another UE 
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receiving the MBMS service that the UE was receiving, the RNC performs an 
operation of deleting the UE from a UE list for the MBMS service in step 1605. 
if there is no another UE receiving the MBMS service that the UE was receiving, 
the RNC transmits to the SGSN an MBMS RAB Release message for releasing 
5 MBMS RAB over which the MBMS data was being received, in step 1606, and 
then receives an MBMS RAB Release Complete message from the SGSN in step 
1607. In step 1608, the RNC deletes the UE from a UE list for the MBMS 
service, and deletes the MBMS service ID from an MBMS list in the RNC. So 
far, the MBMS context management process of the RNC suggested in the present 
10 invention has been described with reference to FIGs. 14A through 16. 

FIG. 17 schematically illustrates a structure of an L2/MAC layer for 
directly transmitting MBMS data from a CRNC to a UE according to an 
embodiment of the present invention. 

15 

In FIG. 17, an SRNC 1701 is an SRNC for managing UEs desiring to 
receive the MBMS service, and assigns MAC-d 1703 for the UE. The MAC-d 
1703 is a MAC entity for transmitting DCCH 1702 for the UE. The SRNC 1701 
transmits an RRC signaling message transmitted from a control plane, using the 

20 DCCH 1702, which is a logical channel. The RRC signaling message, i.e., 
DCCH 1702, can be transmitted via MAC-MBMS 1713 or MAC-c/sh 1715 
according to a CRNC's decision, as illustrated in FIG. 17. The CRNC 1711 can 
determine whether it will transmit MBMS data on a PtP basis or on a PtM basis, 
and in either case, an operation of the CRNC 1711 can be different. If the number 

25 of UEs expected to receive the MBMS service within the CRNC 1711 is larger 
than or equal to a predetermined number, the CRNC 1711 determines to transmit 
the MBMS data on a PtM basis, and if the number of the UEs is smaller than the 
predetermined number, the CRNC 1711 determines to transmit the MBMS data 
on a PtP basis. That is, the CRNC 1711 determines a data transmission method 

30 considering a current cell situation for efficiently utilization of radio resources. 
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However, in this case, even though a cell situation in the CRNC is such that the 
MBMS data should be transmitted on a PtM basis, if a particular UE has moved 
while receiving the MBMS service along with a voice service, the CRNC assigns 
a dedicated channel to the particular UE on a PtP basis, and provides the MBMS 
5 service to the other UEs on a PtM basis. Therefore, in this case, for the same 
service, both the PtP method and the PtM method are available, and a detailed 
description thereof will be described below. 

First, a method of transmitting MBMS data on a PtP basis by the CRNC 

10 will be described. The CRNC 1711 sets up the MAC-MBMS 1713 according to 
corresponding UEs when it determined to transmit MBMS data on a PtP basis in 
a corresponding cell. The set MAC-MBMS 1713 is matched to the MAC-d 1703 
on a one-to-one basis. That is, for one UE, the SRNC 1701 generates MAC-d 
1703, and the CRNC 1711 generates MAC-MBMS 1713, and the generated 

15 MAC-d 1703 is matched to the generated MAC-MBMS 1713. Therefore, when 
the CRNC determines PtP transmission, the RRC signaling message, i.e., DCCH 
1702, is delivered to corresponding MAC-MBMS 1713 via MAC-d 1703, and 
the MAC-MBMS 1713 combines corresponding DCCH with M-DTCH 1712 
which is the MBMS data, and transmits the combined data to a corresponding 

20 UE using DPCH. When transmission paths are separately assigned to respective 
UEs or transport channels on an Iur interface between the MAC-d 1703 and the 
MAC-MBMS 1713, the MAC-MBMS 1713 is assigned a one-to-one 
transmission path to the MAD-d 1703. Therefore, the MAC-MBMS 1713 
directly receives MBMS data transmitted from the MAD-d 1703 over the Iur 

25 interface. The MAC-MBMS 1713 has a function of connecting MBMS data (or 
M-DTCH 1712) for transmitting a signaling message of each UE received over 
the Iur interface according to UEs, to one entity so that a Node B can transmit the 
signaling message with one physical channel. The CRNC 1711 copies MBMS 
data received from an SGSN over an Iu interface according to respective MAC- 

30 MBMSs, and delivers the copied MBMS data to the MAC-MBMS 1713. As a 
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result, C-Plane for transmitting the signaling message (or DCCH 1702) can be 
separated from U-Plane for transmitting MBMS data (or M-DTCH 1712). That is, 
the C-Plane uses an existing path via an SRNC, and the U-Plane uses an Iu 
interface to the SGSN without passing through the SRNC, thereby directly using 
5 a path via the CRNC. The MAC-MBMS 1713 combines the DCCH 1702 of C- 
Plane with the M-DTCH 1712 of U-Plane, passing through different paths, and 
transmits the combined signal to a Node B so that it can be transmitted over 
DPCH. At this point, a transport format set of data passing through the DCCH 
1702 and a transport format set of data passing through the M-DTCH 1712 can 
10 be independent of each other, and a transport format combination is generated by 
combining the transport format sets. As a result, transport format combination 
indication (TFCI) is determined, and a Node B can determine the TFCI. 

Next, a method of transmitting MBMS data on a PtM basis by the CRNC 
15 will be described. 

When the CRNC 1711 determines to transmit MBMS data on a PtM 
basis, the MAC-MBMS 1713 is not generated and DCCH information 
transmitted by the SRNC 1701 is delivered to the MAC-c/sh 1715 via the MAC- 

20 d 1703. In addition, the CRNC 1711 receives MBMS data from an SGSN, 
converts the received MBMS data into M-CTCH 1714, and transmits the MAC- 
CTCH 1714 via the MAC-c/sh 1715. Here, the DCCH 1701 and the M-CTCH 
1714 for a particular UE can be transmitted using a transport channel and a 
physical channel, respectively, without being multiplexed in the MAC-c/sh 1715. 

25 Therefore, the UE separates FACH 1717 for transmitting the DCCH 1702 from 
and FACH 1717 for transmitting M-CTCH 1714, which is MBMS data. It is 
noted that even in this case, the DCCH 1702 is delivered to the UE via the SRNC 
1701, and MBMS data is delivered from the SGSN to the UE via the CRNC 1711. 
That is, U-Plane and C-Plane are separated from each other. In a particular case, 

30 the CRNC 1711 determines to transmit MBMS data on a PtM basis. However, 
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when the SRNC 1701 intends to transmit the DCCH 1702 to a corresponding UE 
on a PtP basis in order to transmit voice, the SRNC 1701 can transmit DCCH 
1702 and voice data over DCH via MAC-MBMS 1713 using the MAC-d 1703 of 
FIG. 17 and transmit MBMS data (M-CTCH 1714) over FACH 1717 via the 
5 MAC-c/sh 1715. In this case, the MAC-MBMS 1713 has a function of simply 
delivering the data. Even in this case, the CRNC can directly deliver MBMS data 
to the UE without passing through the MAC-d 1703. 

As the CRNC 1711 determines to transmit MBMS data received via the 
10 Iu interface on a PtP basis or on a PtM basis according to cells or Node Bs, the 
CRNC 1711 can transmit the MBMS data on a PtP basis by setting up the MAC- 
MBMS 1713, or directly transmit M-CTCH 1714 via the MAC-c/sh 1715. In this 
case, a layer for managing such a function can be additionally set up, and the set 
layer is a layer higher than a MAC layer. For this, an MBMS layer can be set up 
15 which exists over a radio link control (RLC) layer or a PDCP layer higher than 
the RLC layer. The MBMS layer copies data according to whether the data 
received via the Iu interface is determined to be transmitted on a PtP basis or on a 
PtM basis according to respective cells, and transmits the copied data to the RLC 
layer over the M-DTCH 1712 or the M-CTCH 1714 so that they are delivered to 
20 the MAC-MBMS 1713 and the MAC-c/sh 1715, respectively. 

Information exchange between the SRNC 1701 and the CRNC 1711, for 
generating DCH 1716 and FACH 1717, is the same as described in conjunction 
with FIGs. 8, 10, 11, 14A, 14B, 15, and 16. As described above, U-Plane and C- 
25 Plane for an MBMS service have several available combinations according to a 
UE state and an MBMS service type for the new MAC function of FIG. 17 
proposed in the invention, and the available combinations are shown in Table 6. 
The "UE state" refers to CELL FACH or CELLJ3CH. 

30 [Table 6] 
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V 



UE state 


MBMS type 


Combination 


CELLJDCH 


PtP 


Iur interface between a MAC-MBMS and a 
MAD-d and an M-DTCH are used. 


CELLDCH 


PtP 


Iur interface between a MAC-MBMS and a 
MAC-d and an M-CTCH are used. 


CELLFACH 


PtM 


Iur interface between a MAC-MBMS and a 
MAC-c/sh and an M-CTCH are used. 


CELLFACH 


PtP 


Iur interface between a MAC-MBMS and a 
MAC-d and an M-DTCH are used. 



While the invention has been shown and described with reference to a 
certain preferred embodiment thereof, it will be understood by those skilled in 
the art that various changes in form and details may be made therein without 
5 departing from the spirit and scope of the invention as defined by the appended 
claims. 

[EFFECT OF THE INVENTION] 

As described above, the present invention directly transmits MBMS data 
10 from a CRNC to a UE when the UE requesting an MBMS service is handed over 
from an SRNC to the CRNC in an MBMS mobile communication system. Thus, 
a separate Iur interface for transmitting MBMS data from the SRNC to the 
CRNC is not required. Therefore, the present invention advantageously 
maximizes efficiency of radio resources and improves system performance. 

15 
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WHAT IS CLAIMED IS: 

1. A method for providing a packet service to a user equipment when 
the user equipment moves to a second cell managed by a second base station 
controller, the user equipment requesting permission to receive the packet service 

5 in a first cell managed by a first base station controller, in a mobile 
communication system providing the packet service, the method comprising the 
steps of: 

transmitting by the first base station controller control information that 
has to be provided to the user equipment; and 
10 transmitting by the second base station controller the packet service to 

the user equipment via a radio access bearer. 

2. An apparatus for providing a packet service to a user equipment when 
the user equipment moves to a second cell managed by a second base station 

15 controller, the user equipment requesting permission to receive the packet service 
in a first cell managed by a first base station controller, in a mobile 
communication system providing the packet service, the apparatus comprising: 

the first base station controller for transmitting control information 
required for providing the packet service to the user equipment requesting 

20 permission to receive the packet service to the second base station controller; and 
the second base station controller for receiving the control information 
for the packet service from the first base station controller, setting up a radio 
access bearer according to the control information, and transmitting the received 
packet service to the user equipment via the radio access bearer. 

25 

3. A method for transmitting packet service data to a user 
equipment when the user equipment moves to a second cell managed by a second 
base station controller, the user equipment requesting permission to receive a 
packet service in a first cell managed by a first base station controller, in a mobile 

30 communication system providing the packet service, the method comprising the 
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steps of: 

transmitting by the first base station controller a user equipment 
identifier of the user equipment, a service identifier for the requested high-speed 
packet service, and information about a radio access bearer that is currently set 
5 up with the user equipment to the second base station controller; 

requesting by the second base station controller the packet service to a 
gateway providing the packet service using the user equipment identifier and the 
service identifier in order to set up the gateway and the radio access bearer; and 
transmitting by the second base station controller the packet service data 
10 received from the gateway to the user equipment via the radio access bearer. 



4. An apparatus for transmitting packet service data to a user 
equipment when the user equipment moves to a second cell managed by a second 
base station controller, the user equipment requesting permission to receive a 
15 packet service in a first cell managed by a first base station controller, in a mobile 
communication system providing the packet service, the apparatus comprising: 

the first base station controller for transmitting a user equipment 
identifier of the user equipment, a service identifier for the requested high-speed 
packet service, and information about a radio access bearer that is currently set 
20 up with the user equipment to the second base station controller; and 

the second base station controller for requesting the packet service to a 
gateway providing the packet service using the user equipment identifier and the 
service identifier in order to set up the gateway and the radio access bearer and 
transmitting the packet service data received from the gateway to the user 
25 equipment via the radio access bearer. 
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